1. Field of the Invention
The present invention relates to a method and apparatus for communication between wireless devices, and more particularly, to a method and apparatus for transceiving data bi-directionally between two wireless devices during allocated time.
2. Description of the Related Art
Ultra wideband (UWB), also known as digital pulse wireless, is a wireless communications technology for transmitting large amounts of digital data over a wide frequency band at very low power for a short distance. The technology was developed by the US Department of Defense for military purposes. The IEEE 802.15.3 Working Group for Wireless Personal Area Networks (WPANs) is developing a standard for UWB communications. While the IEEE 802.15.3 standard specifies Physical (PHY) and Medium Access Control (MAC) layers, industry research efforts are focusing more on improving the MAC layer.
The IEEE 802.15.3 MAC has the ability to join existing wireless networks rapidly. MAC is also based on an ad-hoc network called a “piconet”, which is controlled by a Piconet Coordinator (PNC) instead of an Access Point (AP), and employs a Time Division Multiplexing Access (TDMA) method. FIG. 1 shows a conventional superframe format. A MAC frame used for data transmission and reception between devices is within a time-slotted superframe structure. Referring to FIG. 1, each superframe consists of a contention access period (CAP) interval during which data is transmitted using a beacon and a backoff algorithm, and a channel time allocation period (CTAP) interval during which data is transmitted without contention during allocated channel time. The CTAP may be replaced by a management CTA (MCTA). The CTAP uses Carrier Sense Multiple Access/Collision Avoidance (CSMA/CA) for contention-based channel access. The MCTA utilizes a Slotted Aloha for channel access.
The CTAP is composed of CTA blocks and MCTAs. There are two types of CTAs: dynamic CTAs and pseudo-static CTAs. In the case of the dynamic CTA whose position can change from superframe to superframe, if a device did not receive a beacon, it cannot use CTA in a superframe. Conversely, in the case of the pseudo-static CTA whose position is fixed in a superframe, CTA can be used as long as the number of consecutive lost beacons is less than mMaxLostBeacons. Since the IEEE 802.15.3 MAC is based on a TDMA that guarantees the Quality of Service (QoS), it is suitable for multimedia audio/video (A/V) streaming in a home network. However, MAC still has several problems that need to be solved in order to enhance throughput as well as QoS.
The IEEE 802.15.3 MAC supports two types of data transfer modes: isochronous and asynchronous.
FIG. 2 illustrates a conventional process of requesting CTA. Referring to FIG. 2, to transmit isochronous data, DEV 1 is assigned a CTA by a PNC using a MLME-CREATE-STREAM.request and a MLME-CREATE-STREAM.confirm. Then, DEV 1 transmits actual data during its allocated channel time using a MAC-ISOCH-DATA.request and a MAC-ISOCH-DATA.confirm.
The PNC informs a device in a piconet (hereinafter called a ‘DEV’) of allocated channel time by sending a beacon so that DEV can know the start and end times of communication.
The source device Src DEV and destination device Dest DEV are designated in the CTA information. In FIG. 2, DEV1 is a Src DEV and DEV2 is a Dest DEV. While only the Src DEV can transmit data during allocated channel time, the Dest DEV cannot necessarily receive the data. Only a DEV with an ‘Always Awake’ bit or ‘listen to source’ bit set to 1 can receive the data.
FIG. 3 illustrates a conventional process for transmitting asynchronous data. Referring to FIG. 3, once data to be transmitted arrives at a MAC layer using a MAC-ASYNC-DATA.request, DEV1 that is a Src DEV sends a channel time request command frame to a PNC. Then, after being informed through a beacon that its channel time request has been granted, the Src DEV sends data during the allocated channel time. Like isochronous data transfer, a pair of Src DEV and Dest DEV are designated in CTA information and only the designated Src DEV can transmit data during its allocated channel time. Also in FIG. 3, DEV 1 is Src DEV and DEV 2 is Dest DEV. Another method for transmitting asynchronous data is to send a frame using a backoff algorithm during a CAP.
In TCP/IP (Transmission Control Protocol/Internet Protocol), to ensure timely transmission of data, if DEV1 transmits a frame, DEV 2 sends an acknowledgement (ACK) frame (a TCP/IP ACK frame, not the immediate (Imm)-ACK frame shown in FIG. 2 or 3) to DEV 1. When a data transmission mechanism supported by the IEEE 802.15.3 MAC is used by the TCP/IP protocol, the following problems occur.
Firstly, isochronous TCP/IP data transfer will be described. To establish a connection between DEV 1 and DEV 2, DEV 1 requests a CTA, in which Src DEV is DEV1 and Dest DEV is DEV 2, from a PNC by sending a MLME-CREATE-STREAM.request to the PNC. When the PNC allocates channel time and sends a beacon carrying CTA information, DEV 1 reads the beacon and transmits a frame to DEV 2 during its allocated time. In order to send a response frame, DEV 2 requests CTA, in which Src DEV is DEV 2 and Dest DEV is DEV 1, from the PNC. Similarly, when the PNC allocates channel time and sends a beacon carrying CTA information, DEV 2 reads the information included in the beacon and transmits a response frame to DEV 1 during its allocated time.
Since channel time continues to be allocated until a MLME-TERMINATE-STREAM.request is received, subsequent data and ACK frames will be sent to DEV 1 and DEV 2 during time assigned to Src DEV and Dest DEV according to CTA information in a beacon. However, in TCP/IP, a sender never transmits a new frame until it receives an ACK frame for the previous data frame. On the other hand, the IEEE 802.15.3 MAC permits only a Src DEV designated in the CTA contained in the beacon to transmit data during its allocated channel time. Thus, DEV 2 has to wait a while until DEV 2 is designated as Src DEV, before sending a TCP/IP ACK frame. That is, DEV 1 cannot receive an ACK from DEV 2 during the remaining portion of the channel time (assigned to DEV 1 and DEV 2 after sending data), resulting in a waste of channel time.
Secondly, asynchronous data transfer will be described. When asynchronous data is transmitted in a CAP, a PNC may allocate a CAP in a superframe. Even if there is an allocated CAP, it is determined whether asynchronous data transfer is permissible during the CAP depending on criteria set by the PNC. Using CAP cannot guarantee the timely transmission of a TCP/IP frame. To send asynchronous data using CTA, DEV 1 uses a MAC-ASYNCH-DATA.request as described above. As illustrated in FIG. 3, DEV 1 has to send a channel time request command to the PNC and be allocated channel time by the PNC before transmitting each data frame. Thus, transmitting data consecutively leads to a waste of bandwidth. Furthermore, DEV 1 (requesting a CTA) cannot know when the requested time will be allocated so it has to wait until at least the beginning of the next superframe each time a data frame is sent. This leads to transmission delay.
The above problems may also be raised when a protocol other than TCP/IP resides above the IEEE 802.15.3 MAC.